Support the .NET 11 SDK band and net11.0-tizen TFMs - #310

Maintainer action required: approve fork workflows

GitHub created all required PR runs, but they are in action_required and can only be approved by a repository administrator:

• Build Workload: https://github.com/Samsung/Tizen.NET/actions/runs/33003725323
• Validate Version Map: https://github.com/Samsung/Tizen.NET/actions/runs/33003725333
• Build Matrix: https://github.com/Samsung/Tizen.NET/actions/runs/33003725364

Please use Approve and run workflows on these runs. Until then, the PR has no CI status even though the .NET 11 manifest pack/install/template/build/TPK chain was validated locally as described in the PR.

Review fixes pushed — 9cdce68

All four code-review findings and all ten MSBuild-review findings are addressed. One item (#14) is reported as provably non-applicable with evidence rather than changed.

Code review

MSBuild review

#14 — RuntimeList.xml: proven not XML-parsed, left unchanged

The file does have multiple root elements. I checked the consumer contract empirically rather than assuming:

1. Microsoft.NET.Build.Tasks.dll does contain RuntimeListNotFound / absoluteRuntimeListPath, so the SDK can read a runtime pack's RuntimeList.xml — a static grep alone would have been misleading.
2. So I tested the path that actually resolves runtime pack assets: a net11.0-tizen11.0 build with an explicit RuntimeIdentifier=tizen-x86 (what MAUI takes via EnableImplicitRuntimeIdentifiers). Built clean.
3. Decisive test: replaced the installed pack's RuntimeList.xml with the literal text <<< THIS IS NOT XML AT ALL &&& >>> and rebuilt the same RID-specific project → Build succeeded. 0 Error(s).

Samsung.NETCore.App.Runtime.tizen is a placeholder pack whose only payload is lib/net6.0-tizen/_._, so nothing reads the file. Making it well-formed would need a non-standard wrapper root or splitting the pack per .NET version — more risk than the malformed file carries while unread. C6 parses it line-wise, matching how it's produced. Documented in workload/docs/net11.md with the revisit criteria.

Validation on 11.0.100-preview.7.26381.103

Full matrix 6/6 pass, 0 skipped — net8.0-tizen10.0, net8.0-tizen10.1, net8.0-tizen11.0, net9.0-tizen10.0, net11.0-tizen11.0, net11.0-tizen10.0.

make check: C1–C8, 11 self-test, 61 version-band (bash ↔ PowerShell ↔ Config.mk, fallback family, band isolation), 13 template-condition, 4 install-failure assertions, plus version-map drift and install-script integrity. Docs updated to describe the corrected behaviour.

Unrelated observation

tizen.myget.org now returns HTTP 401 to anonymous clients (.../api/v3/index.json). It remains a push target in build-workload.yml's deploy job. I have not touched it — removing a publishing destination is a maintainer call — but it's noted in workload/docs/net11.md in case any docs still point consumers there for restore.

Updated workflow approval request for head 9cdce68

The review-fix push created replacement runs, all currently action_required:

• Build Workload: https://github.com/Samsung/Tizen.NET/actions/runs/33007312794
• Validate Version Map: https://github.com/Samsung/Tizen.NET/actions/runs/33007312866
• Build Matrix: https://github.com/Samsung/Tizen.NET/actions/runs/33007312943

Please approve these newer runs; the earlier links target superseded head b847341.

Merge-readiness validation at head 9cdce68 (clean-tree re-run)

Re-validated from a fully cleaned tree. No code changes were needed — head is unchanged at 9cdce68 and the existing approval request still points at the current run IDs.

Manifest ID / version — .NET 11 supported, old bands unaffected

Built the manifest package for three bands from the clean tree:

The .NET 11 manifest declares Samsung.Tizen.Ref.API15 → 15.0.0.19396, the targeting pack for net11.0-tizen11.0.

Diffed the 10.0 build against the actually-published Samsung.NET.Sdk.Tizen.Manifest-10.0.100 10.0.123 from nuget.org:

• package id: identical
• WorkloadManifest.targets: byte-identical
• WorkloadManifest.json: differs only by the additive Samsung.Tizen.Ref.API14 / API15 pack entries — introduced by base-branch commit 44d7bdf, which predates this branch point. git diff 5e13077 HEAD -- .../WorkloadManifest.in.json is empty; this PR does not touch that file.

Feature-band change: proven non-regressive

The Config.mk rounding fix (finding #10) changes the manifest package ID, so I verified it against every one of the 37 bands in version-map.json, comparing the pre-change logic (reconstructed from base commit 5e13077) with the current one:

identical: 37   differing: 0

It differs only for non-round patch versions, where the new value is the correct one:

End-to-end, both bands, one tree

The 10.0 run is the direct refutation of finding #1: net8/net9 rows now build on a .NET 10 SDK and only the genuinely-unbuildable net11 rows skip. Previously every row skipped and the job built nothing.

Both SDKs coexist under out/dotnet-10.0.100 and out/dotnet-11.0.100-preview.7, confirming the band-isolation fix (#6).

make check on the clean tree: C1–C8 plus 89 assertions (11 self-test, 61 version-band, 13 template-condition, 4 install-failure), version-map drift and install-script integrity — all green.

Pre-existing issue found (NOT introduced here, NOT fixed here)

The .NET 9 band cannot be built on this branch, independent of these changes:

error: Unable to find package Microsoft.DotNet.SharedFramework.Sdk with version (= 9.0.0-beta.25065.2)

Evidence it is pre-existing:

• the pin was added by commit 86fcc19 (2025-11-19), long before this branch;
• git diff 5e13077 HEAD -- workload/build/Versions.props shows my edits are purely additive (the 11.0 block + DotNet11SdkVersion) and do not touch the 9.0 pin;
• 9.0.0-beta.25065.2 exists for Microsoft.DotNet.Arcade.Sdk but not for Microsoft.DotNet.SharedFramework.Sdk on dotnet-eng (nearest real versions present in both: 9.0.0-beta.25058.5, 9.0.0-beta.25077.4).

Only the 9.0 pin is affected — 8.0, 10.0 and 11.0 all resolve.

I have not changed it: it is outside this PR's scope, and I cannot validate a 9.0 pack-output comparison precisely because the band doesn't build today. Flagging it because one consequence of finding #8's fix is relevant: with continue-on-error removed from release-workload.yml, a release run for the 9.0 band will now fail loudly instead of silently proceeding to the push step. That is the intended behaviour, but it means this latent breakage becomes visible.

Remaining blocker

Only maintainer approval of the fork workflow runs. All three remain action_required at the run IDs listed in the previous comment; no new runs were created because the head did not change.

New head 6fffd09 — all code + MSBuild review blockers addressed

Maintainer action required: approve fork workflows for the NEW head

The previous runs were superseded. All three replacement runs are action_required:

• Build Workload — https://github.com/Samsung/Tizen.NET/actions/runs/33070345680
• Build Matrix — https://github.com/Samsung/Tizen.NET/actions/runs/33070345658
• Validate Version Map — https://github.com/Samsung/Tizen.NET/actions/runs/33070345715

Installers

Fallback now resolves the package ID, not just a version. getLatestVersion /
Get-LatestVersion return "<packageId>=<version>". Verified live against nuget.org using the
reviewer's exact example:

End-to-end run installs the 10.0.300 package into the 10.0.400 band directory, as intended.

$global:FallbackId removed. Verified with a live two-SDK -UpdateAllWorkloads run:
10.0.404 → falls back and installs; then 11.0.100-preview.7 → fails closed (Wrong Id),
overall exit 1, and no 11.x manifest directory is created. Previously the 10.x fallback id
persisted into the next iteration.

bash 3.2 (macOS). ${MANIFEST_NAME,,} is bash 4+; on macOS it raised bad substitution,
left the version empty and silently skipped the fallback entirely — making the fix above
unreachable there. Replaced with tr. An empty/failed query now takes the same path as
BlobNotFound, and a failed download fails closed. Install/temp paths are quoted; a real
install into dir with spaces/dotnet sdk is now a test.

NuGet fallbacks

FixupNuGetReferences matches lib/<name>/ by name only, so the list must be filtered.
Candidates are emitted only when both .NET version and platform version are <= the
project's, appended highest-first. Negative assertions now guard exactly the leaks called out:

Deleting the filter makes the test fail with explicit LEAKED: diagnostics.

Built from conditional properties, not items — MSBuild evaluates all top-level properties
before items, so an @(item) reference there silently expands to nothing (this bit me first
attempt).

Runtime metadata — correcting my earlier claim

You are right that RuntimeList.xml is parsed, and my earlier "never parsed" note was wrong.
It is retracted in the docs. Microsoft.NET.Build.Tasks carries the literal RuntimeList.xml
next to the runtime-pack manifest fields ResolveRuntimePackAssets reads (Managed, Native,
PgoData, AssemblyVersion, PublicKeyToken). My earlier test used a framework-dependent
RID build, which never reaches that task.

Both remediations applied:

1. The file is well-formed (single <FileList> root, legitimately empty — the pack ships
   only lib/net6.0-tizen/_._).
2. Self-contained is rejected with TIZENSDK001 and an actionable message.

One precise scope note: with the guard bypassed and the malformed file restored, this
configuration failed at NETSDK1083 (RID resolution) before reaching
ResolveRuntimePackAssets, so I could not reproduce a raw XmlException here. I'm reporting
that rather than claiming a repro I didn't get. The malformed file was still a latent hazard on
any path that does reach the task, and both fixes stand regardless of which error surfaces first.

Release

• Notes reuse the staging step's verified band and manifest id. ${SDK%%-*} produced
  11.0.100 for 11.0.100-preview.7.* and 10.0.404 for a servicing band — both linking to
  packages that were never published.
• The version bump is now committed and pushed, and the tag targets that commit. Previously
  the bump was runner-local, so the tag pointed at sources still carrying the previous version.

Coverage

• Matrix gains explicit net10.0 rows (10.0/10.1/11.0) plus net11.0-tizen10.0 → 9 TFM
  rows, plus a self-contained disposition assertion.
• .NET 11 now blocks by default (TIZEN_NET11_ADVISORY=true downgrades it). The SDK version
  is pinned exactly, so the leg is deterministic — and a branch whose purpose is .NET 11 support
  gains nothing from an advisory-only .NET 11 gate.

Validation on 11.0.100-preview.7.26381.103

Matrix 9/9 TFM rows + self-contained assertion, 0 skipped:
net8.0-tizen{10.0,10.1,11.0}, net9.0-tizen10.0, net10.0-tizen{10.0,10.1,11.0},
net11.0-tizen{10.0,11.0}, and PASS self-contained rejected with TIZENSDK001.

make check: C1–C8 plus 110 assertions — 11 self-test, 61 version-band
(bash ↔ PowerShell ↔ Config.mk), 13 template-condition, 6 package-fallback, 19 install-failure
— all under bash 3.2, including the space-path install and an unreachable-feed case.

Environmental note (not a repo defect)

On this machine the freshly extracted .NET 11 preview SDK cannot run RoslynCodeTaskFactory
(MSB3755 for mscorlib/netstandard), so make packs fails under it. The same sources
pack cleanly under .NET 10.0.400, producing Samsung.NET.Sdk.Tizen.Manifest-11.0.100-preview.7
correctly, and the resulting workload installs into and builds with the .NET 11 SDK. Flagging in
case CI hits it; I could not attribute it to anything in this branch.

Approval links are already current for 6fffd09 — plus which runs to ignore

No refreshed request is needed: the three links in my previous comment already point at the runs created for the current head.

✅ Approve these three — they are for head 6fffd09 (current):

⚠️ Do NOT approve these — superseded heads, still sitting in action_required:

• 9cdce68 — Build Workload / Build Matrix / Validate Version Map
• b847341 — Build Workload / Build Matrix / Validate Version Map

Because every push from a non-member fork queues a new set awaiting approval, older sets linger in the Actions tab and look identical apart from the commit SHA. Approving one of those would run CI against superseded code and report a result that does not describe the current head — worth knowing before clicking, since the older heads lack every fix from 6fffd09.

The GitHub Actions run list can be filtered to the current head with:

https://github.com/Samsung/Tizen.NET/actions?query=branch%3Aredth-net11-tizen-workload

then matching the commit SHA column against 6fffd09.

Head is being held stable at 6fffd09 pending the exact-head reviews; I will not push unless a reviewer reports a real blocker.

New head c26d236 — all five exact-head blockers fixed

Maintainer action required: approve fork workflows for head c26d236 ONLY

⚠️ Runs for 6fffd09, 9cdce68 and b847341 are also queued in action_required and must not be approved — they would test superseded code.

1. PowerShell empty versions

An empty/all-blank versions[] made Select-Object -Last 1 yield $null, so the function returned "<id>=" — truthy. The caller split off an empty version, and the NuGet v2 endpoint serves the latest package for a versionless URL. Blank entries are now filtered, an empty result falls through to the retry/version-map path, and the caller rejects an empty id or version. The shell installer gained the same guard before the download.

2. Shell SDK pinning

install_tizenworkload runs under if !, which disables errexit for everything it calls — so the unchecked dotnet new globaljson let the install proceed on the wrong SDK. The pin now uses the dotnet under test, its exit status is checked, and the effective dotnet --version and feature band are re-verified before any pack is installed.

Verified with a stub whose pin silently doesn't take effect:

SDK pin did not take effect: requested 10.0.100, active 9.0.100.
FAILED to install Tizen workload for sdk(s): 10.0.100
exit=1

REACHED_INSTALL never printed. The matching effective-pin case still installs normally.

3. Release versioning / resume

Persistence now happens only after the build succeeds and artifacts are verified. OLD == NEW resumes instead of aborting — next-workload-version.py derives from what's published on NuGet, so the branch may legitimately already carry the intended unpublished version. Reference-only runs are fully non-mutating; re-creating an existing tag is a no-op. Order is pinned by 14 assertions.

4. Fallback priority and atomicity

FixupNuGetReferences collected every match into an unordered HashSet (populated in filesystem-enumeration order) and took assemblies first-wins across all of them. It now ranks candidates by their position in PackageTargetFallback, selects exactly one fallback TFM per package, and takes every substituted assembly from that single directory.

One thing I want to be straight about: the new tests build the candidate directories in both creation orders so the assertion can't depend on filesystem enumeration, and they pass. But I could not construct a case where the old implementation demonstrably failed on this machine — directory enumeration here happened to favour the correct answer in every variant I tried, including reversed creation order and a package where only the lower-priority TFM carried the second assembly. So the tests lock in the correct contract going forward, but I can't claim to have empirically reproduced the mis-selection; the fix rests on the code path being order-dependent by construction, which the diff makes explicit.

5. Self-contained matrix outcome

An unexpected diagnostic previously warned and passed. Anything other than TIZENSDK001 — including NETSDK1083 or an accidental success — now fails CI, as does being unable to prepare the fixture.

Validation

make check green: C1–C8 + 135 assertions — 11 self-test, 61 version-band, 13 template-condition, 12 package-fallback, 14 release-workflow, 24 install-failure — all under bash 3.2, including installs into a space-containing path, an unreachable feed, and a pin that doesn't take effect.

The 9-row TFM matrix and self-contained assertion were verified on 11.0.100-preview.7.26381.103 at 6fffd09; this head changes the installers, the fallback task, the release workflow and tests, and make check covers all of them. Full-matrix re-verification will come from the CI runs above once approved.